The Video-On-Demand (VoD) system is an electronic solution to deliver movies to remote users over a broadband computer network. It implements an electronic video-rental store that supports interactive facilities of video playback stations over a computer network while eliminating the inconvenience to the users of associated video-cassette rental problems.
Another advantage of the VoD system over usual broadcast TV or cable TV is the possibility to the user to watch a movie at any time, pause the movie at any moment, forward, and rewind it as the user wishes.
The general architecture of the VoD system is composed of 3 parts: At one end is the VoD server 10 in which movies are stored, in the middle is the data communication network 20 which transports the flow of digitized movie frames, and at the other end is the client stations 30. The client station can be a TV with a decoder box (setup box), a computer, or even a TV with an embedded computer.
The general mechanisms of a VoD System are very simple. The client requests electronically a movie that has been chosen from a video catalog accessed by an Internet browser. Once a new connection is establish between the VoD server and the client machine, the server sends a video stream across the network to the client machine. During the movie exhibition, the user can execute pause/resume, fast forward, or rewind operations. When such operations are requested, they are sent to the server, which will interrupt the video stream if a pause command was executed or it will send the video stream at a higher speed in reply to a fast-forward operation request. These and other commands can be executed by the server itself or by specialized agents that help the server by sharing the server workload.
The basic issue of a VoD system is scalability in the sense that the system has to support an increasingly large number of users without having to increase the server resources linearly. Current solutions scale the system, but the resulting system is more limited than the original one, for instance, it offers neither VCR facilities nor the option to start a movie at any instant of time. Usually such techniques use a multicast stream with mechanisms for batch, bridging, or piggybacking, which try to group two or more streams into one stream for multicasting. To start video exhibition at any time, another solution that has been proposed is patching, which uses another channel to download the initial portion of the movie while the current movie stream is buffered at the client; yet, this technique doesn't allow VCR operations.
An attempt to allow pause/resume operations using multicast with the techniques referred above, is to use a large buffer in the client in such a way that if the client wants to pause and resume afterwards, the client will have the movie available in the local buffer. In this way, the server will have more time to complete the resume operation. The same scheme works for both ff and rw operations. Although such a mechanism works at low operation rates, the chance of blocking at higher operation rates is considerable. This happens because the server may have all of its resources occupied attending other requests while the client buffer becomes empty. A common solution used to alleviate this problem, is to reserve some server resources to answer VCR operations, even though the allocated resources may not be sufficient and the system will block.
An obvious conclusion is that one of the system bottlenecks is the server capacity and a solution to that is to increase the number of servers. Using several servers or an expensive server with enough capacity to sustain a large number of video streams will lead eventually to network congestion, specially in the network link between the server and the network, even using multicast. So, another system bottleneck is the bandwidth of the network link to the server and one solution to increase server bandwidth is to distribute the server across the network, which also increases the system costs.
One interesting idea is the one that tries to avoid the server bottleneck by chaining the client buffers so as to build a delay line. Chaining improves the capacity of the system by recycling the video stream that is discarded after the exhibition, redirecting it to another client that can make use of it. The redirection may be extended indefinitely, forming long chains through which video streams can be propagated. Using chaining we can buffer a huge amount of videos in the system, which can be reused to generate new video streams using multicast.
Our invention is new in the sense that it uses the buffer storage space not only as a delay line, but also as a single view of memory space that can be managed in a cooperative way to offer VCR facilities to the VoD system in a scalable manner. The resulting VoD system has the following advantages:                1—the user can watch the exhibition of a movie of his/her choice “quasi” instantaneously, without the need to wait either for the buffer to fill up or to the next slot of a multicast transmission;        2—the user can forward or rewind any movie portion continuously not only the stored movie stream while alleviating the server from the burden of using exclusive video streams to support interactive functions;        3—to be scalable by minimizing the server access when the movie is cached in the collective memory;        4—to be more fail-tolerant, since existing copies of the movies in the collective memory can be used as alternative video streams under unexpected events, such as network failures;        5—to guarantee Quality of Service, since the mechanism we devised can adapt to changes of network traffic variation.        